Playing Xconq
*************

This chapter is about how to play Xconq. Although Xconq supports a wide variety of games, and runs on many different computer systems, they all have much in common, and it is these common features that will be described here. This chapter, along with the document for your system and the document for the game you're playing, should provide all the information you need to play and enjoy Xconq.

The term interface refers to the particular graphical user interface in use.  Examples include X11 basic, X11 toolkit, curses, Macintosh(tm), and ``dumb terminal'' (used for testing). Interfaces can vary radically from each other, since each is designed to be best suited for its environment. However, all have some way to display the world, all have a way to examine individual units, and all provide some way for you to make your units do actions. In practice, interfaces will also tend to share the same commands, so that you don't learn to learn a whole new set of commands when switching computers.

When reading this chapter, you should be aware that the term game is more precisely game design, since it is the set of rules and definitions of the game you want to play.  Since Xconq allows for many different kinds of games designs, much of the information in this chapter will be irrelevant to a particular game.  This will be indicated by phrases like ``some games'' or by saying that a game ``may'' implement some concept or behavior.  You should learn what the game you're playing actually does in these cases. The names of the variables or tables to look at will often be mentioned in computer type like this.

Setting Up A Game
=================

To get started with an Xconq game, you have to select the one that you want to play. The possibilities may be presented to you, or you may have to look in some sort of library to see what's available and then supply that name on a command line. If you don't do anything, then you will get some sort of default game.

Some games require no additional setup; once loaded, you're ready to go. Others will require additional decisions, such as the size and shape of the playing area, whether exploration will be necessary, or whether the game is realtime. These will all be called variants. The exact set of variants is determined by the game design, and the interface will (usually) tell you about them.

In addition, most games also give you a choice of which player is to play which side in a game, as well how many players can join in. There are two kinds of players: humans, who have displays, and artificial intelligences or AIs for short, which are run by the computer.  Your version of Xconq may support more than one kind of AI; each type has a distinct name.

An example might be a simulation of pre-WWI Europe, named "la-belle-epoque", in which the sides might be ``England'', ``France'', ``Germany'', and ``Austria-Hungary'', and the players might be Joe on a Sun-4, Natalie on a Mac, and two of the mplayer type AIs.  You can set Natalie to play England, Joe to play Germany, and the two AIs to play France and Austria-Hungary.

Some game designs provide a way to even things up if the players are of vastly differing abilities. In these designs, each player has an initial advantage that affects how much he or she gets to start with. Weaker players should get a higher advantage, so for instance a game of two players of advantages 1 and 4 might give the advantage 4 player 8 cities while the advantage 1 player gets only 2. This affects setup only; during the game all players are equal. The variability of advantage also depends on the game; some may allows differences of 10 to 1 or more, while others, especially historically accurate scenarios, will have a fixed advantage that the designer has set for each side.

Once a trial player setup has been made, Xconq runs ``synthesis methods''. These methods are specified by the game design, and randomly generate anything that was not explicitly spelled out; for instance, the initial location of countries, terrain features, and so forth. As a player, you don't have to concern yourself about synthesis methods, but you should be aware that you may sometimes run into situations were a synthesis method simply cannot cope, and your game setup will fail.  A common case is where you ask for many players to be set up in a small world, and the set of constraints is too ``tight'' for an initial setup to succeed.  In such cases, you just have to try different setups and maybe complain to the game designer (or to the Xconq author!). Synthesis methods may also take a long time to run; for large worlds and lots of players, be prepared to wait.

When initialization and setup succeeds, Xconq will try to open up displays for every player that wanted one. Exactly how this happens depends on the interface and networking capabilities of the version of Xconq you're using. Once this is done, Xconq will start the game for real.

[any other setup warnings to document?]

Mixing Game Modules
-------------------

Some interfaces (such as those using Unix-style command lines) may let you ask for more than one game design when starting up. This is sometimes useful, for instance, if you want to play on the steppes world with a non-standard set of units; your command line might look like -g my-hacks -g steppes. Be aware, however, that this cannot be guaranteed to work always, since the mixed-together game designs may have mutually conflicting definitions, or interfere with each other in subtle or not-so-subtle ways.  Just imagine the disaster if the world consists entirely of terrain that is instant death to your initial units!  Worse, Xconq may start up and run OK for awhile, then crash and burn for no apparent reason.

So be careful about mixing designs!

Starting Play
=============

Exactly what you'll first see depends entirely on the interface you're using. Help is available in the ``usual'' ways, and the interface is robust, so you can always just try to find your way around by experimentation. (This is best done by yourself, rather than in a game with a lot of other people.)

The game proceeds as a sequence of turns. During each turn, you and the other players get to move your units, which can be anything from cities to submarines to insects, depending on the game. In addition, there may be backdrop activities, such as changing seasons and weather, that go on all by themselves. These typically happen at the beginning or end of a turn, not while players are moving their units.

Your exact goal in the game depends on the scorekeepers. Most games have at least one, some have several, and some have none. There are many kinds of scorekeepers, so be sure you know and understand what they are before getting too far into a game! There may not be any scorekeepers at all, in which case you can do whatever you like; any AIs playing in such a game will also do what they like.

A game may last anywhere from a few turns to many hundreds. Again, this may be limited by the game design, or perhaps by the nature of the game.  For instance, a game of oil empires might be forced to end when the world's oil supplies are exhausted...

Worlds and Areas
================

     Gallia est omnis divisa in partes tres [All Gaul is divided into three parts] -- JULIUS CAESAR

The Xconq ``world'' is always a sphere.  However, you only play on a piece of it, which is called an area. Currently, there can only be one world and one area in a game.

An area is divided into hexagonal cells.  Although squares with four or eight neighbors could be used (and were, in the very first version of Xconq), hexes have better all-around geometric properties. Each cell is adjacent to six others, in the directions NW, NE, W, E, SW, and SE. Areas have a width and height that are the number of cells across and up/down. Although you can ask for areas down to 10x10 or less, or up to 1000x1000 or even more, the ideal default is typically around 60x30.  Larger areas consume vast quantities of memory, plus they're slow and unwieldy to play on.

An area may be large enough to go all around the world, forming a cylinder shape. The cylinder can be circumnavigated in an east-west direction. This is an 8x6 cylinder:

     # # # # # # # #
      : : + + : : : :
     : : : + ^ : : :
      : : : : : : : :
     : : : : ^ : : :
      # # # # # # # #

Areas whose width is less than the world's circumference have a hexagonal shape. This is an 8x7 hexagon:

        # # # # #
       # : + + : #
      # : : + ^ : #
     # : : + ^ : : #
      # : : : : : #
       # : : ^ : #
        # # # # #

The top and bottom rows of the cylinder shape, and all the sides of the hexagon shape, although they are displayed, may not be entered (except when leaving the world entirely, see below).  These cells are called edge cells.

The types of terrain you'll find in the world depends on the game design; typically there will be sea, land, mountains, swamp, and so forth, but more exotic games have been known to feature junkheaps, lava, and black holes as ``terrain''.

Terrain can appear either to cover an entire cell or as linear features passing through or between cells. Cell terrain covers the entire cell uniformly, right out to its edges. A border is the boundary between two adjacent cells; it has a distinct terrain type, such as ``river'' or ``beach''. A connection is a narrow ribbon of terrain that reaches from the middle of one cell to the middle of an adjacent cell. Like borders, connections are distinct types, for instance ``road'', ``railway'', or ``canal''. Connections take precedence over borders and underlying cell terrain; in other words, if cell or border terrain is impassable, but there is a passable connection type, then the connection allows passage. Thus a connection can be usable as a bridge.

You may also find more than one type of connection or border, between two cells, such as both a road and a rail line. This occurs only in the more complex games.

A coating is like snow; it is a type that co-exists with cell terrain.  Coatings can change from turn to turn, varying in depth.

Note that any single terrain type can only play one of these roles. This means you will never have river terrain that is both border and connection, nor will snow be both a coating and a cell type.

In some games, each cell has an elevation, which is basically elevation above sea level, but could be any range of values, as set by the game design. The game design also defines the effect of elevation on movement, visibility, and weather.

A world can have named geographical features, such as a bay, mountain, desert, or valley. Geographical features never have any direct effect on your game, but some interfaces may use them to help describe locations, in phrases like "1 hex NW of Broken Hill".

A world can have people living in some or all of its cells. People belonging to a side report everything they see in their cell to their side. Some types of units will change the people's side to the unit's, if that unit is of the proper type.

Units
=====

Units can be almost anything: adventurers, armies, balloons, bicycles, dragons, triremes, spiders, battleships, bridges, headquarters, cities. Units move around, manufacture things, fight with other units, and possibly die. They are the playing pieces of Xconq.

Units have a location, either in out in the open or inside some other unit. In games that define connections (like roads), a unit may be on the connection rather than on the predominant terrain of the cell. (Think of a truck on a bridge.) Some games may also have airborne and subsurface units. There may be more than one unit in the open in a given cell, up to a game-defined limit. A unit inside another unit will be called an occupant in a transport, even if the ``transport'' is a type that can never move.

A unit either belongs to a side, or else it is considered independent. Independent units do not do very much. In the more complex names, the unit's side merely represents the current ownership, and the unit may have a range of feelings towards each side, including its current one. In those games, it is possible for a unit to be a traitor!

Units can have a name, full name, a title, and a number, as appropriate to the situation. The name is an ordinary name like ``Joe Schmoe'' or ``Cincinnati'', while the full name might be something like ``Joseph P. Schmoe''. The title is a form of address such as ``Lord''. The unit number, if used, is an ordinal that is maintained for each side and each unit type, so you can have both a ``1st national bank'' and a ``45th infantry division'' on your side. Names and numbers are always optional, and can usually be changed at any time during the game.

Every unit starts out with a number of hit points or hp representing how much damage it can sustain before dying. Certain types of units, such as armies and fleet of ships, have multiple parts, which means that damage to them reduces their effective size. Multi-part units can merge with and detach from each other. Damaged unit may recover their hp on their own, or else repairable by explicit action.

In addition to occupants, a unit can also carry materials (food, fuel, treasure, etc). These materials are known as the unit's supplies. Supplies are used up by movement, combat, and by just existing, and are gotten either by producing them or by transferring them from some other unit. Some games start units out with lots of supplies, while in others you have to acquire them on your own.

What a unit can do at any one time depends on the action points or acp available to it.  Each sort of action - movement, construction, repair, etc - uses up at least one action point, and possibly more. A unit with an acp of 0 can never do anything on its own, although other units can still manipulate it. Also, not every type of unit can do every type of action; this is also defined by the game design. Section xxx lists all the types of actions that are possible in Xconq.

You can lose a unit in many different ways: in combat, by running out of essential supplies, by being captured, by revolt, by garrisoning a captured unit, by leaving the world, or in accidents.

Materials
=========

In Xconq, materials are basically bulk inanimate stuffs, like food or fuel. They are kept in units or in cells, up to a maximum defined by the game. Materials may be provided as part of the initial game setup, or else produced by units and cells. They are consumed by construction, movement, or merely in order to surive. You can also move materials around from unit to unit, or (in some games) let the laws of supply and demand move them for you.

In a few games, possession of a material type may figure into your score (your gold for instance). In other games, there are no types of materials at all.

Sides
=====

Each player in Xconq runs a side. The concept of ``side'' is somewhat abstract in Xconq; units in a game belong to sides, but the sides themselves are not attached to any particular unit (with the partial exception of ``self-units''; see below for details). Side often represent countries, but not always.

It is important to be clear about sides and players. A side is a part of the simulated world, while a player is the actual real-world person or program that is playing the side. You yourself are always the player, but in one game you may play the German side, and in another the Klingon side. During a game, there will always be a player for each side, and vice versa.  The distinction is most important during setup; you can swap players between sides.

Each side can have a name and associated parts of speech, such as a noun for individuals on the side and an adjective to describe anything belonging to the side. Sides can also have emblems and colors that are used in displays. Some game designs preset all this, while others let you personalize as desired. See the Xconq document for your system to learn how to do this.

Interaction Between Sides
-------------------------

In games with two players, your interaction is usually pretty simple, i.e. bash each other.  In games with many players, some human, some mechanical, it is possible to have a variety of relationships, ranging from complete trust to complete hatred.

One thing you can do is to make your side be controlled by another side. This is basically surrendering, because the controlling side can manipulate any of your units as if they were its own.  The controlling side also has the option of allowing or forbidding you to move your own units.  The relationship is strictly one-sided, and only the controlling side can release the controlled side.  (Note that this is a way to do governors, where one player is the main boss and is helped by several other players acting as governors, usually with agreed-upon responsibilities.)

A less extreme, but still very close, relationship is trust.  This is like a close ally - you can enter each other's transports, you share view data, and so forth.  Trust is a two-way relationship; both you and the other side each have to declare you want to trust the other. Trust can be unilaterally withdrawn.

If you don't want to declare a special relationship with another side, but still want to make some sort of adhoc arrangement, you can create an agreement.  An agreement is a sort of generalized treaty; it consists of a number of terms agreed to by a number of signers, which are sides.  Agreements may be public or secret, and you can declare them to be enforced by Xconq if the terms are in a form it understands (obviously, an agreement that just says ``help each other out'' cannot be evaluated by the program).

To make an agreement, you ask the interface to create one, fill in its terms, possibly give it a name, and make up a list of proposed signers. Xconq will then ask each signer for a tentative signature, if all tentatively sign, then the agreement becomes genuinely signed and goes into effect immediately.  All sides that are to know about the agreement will be informed of its terms. [have both public and secret terms?]

Some interfaces may allow players to copy and modify a proposed and circulate it along with the original.  The proposing side may also withdraw a proposal, but cannot modify it without having it signed again by everybody involved.

Once in effect, an agreement cannot be modified, and it cannot be removed unless it includes a term that provides for this.

Each term of an agreement can have one of several forms:

A text string.  This is not interpreted in any way and could be a comment, preamble, or whatever.

A true/false expression.  This must always be true for the agreement to be valid.

A statement of an action.  This action will be performed at the instant that the agreement goes into effect.

An if-then statement.  If the condition is true while the agreement is in effect, then the action will be performed.

[need some examples]

Trade with Other Sides
----------------------

You can specify the nature of the trading relationship with other sides. The basic theory is that traders are businessfolk and don't care much about politics; they will do business with anybody. However, a player can define relationships with other sides via tariffs. A tariff is a per-side per-material value that is the percentage of material that will be claimed from the amounts going both to and from units on a side. [does this mean we need both import and export tariffs?] A tariff of zero means free trade, while negative is allowed and amounts to a subsidy.

Tech Levels
-----------

In some game designs, technology and research are important. These games give each side a set of tech levels or just tech, one for each type of unit. The tech level represents the technological knowledge needed to see, operate and build a type of unit. Tech levels never decrease (they can in real life, but only over very long time intervals), and they can be increased by research and espionage.

There are several thresholds that you must reach to do things with a unit.  First there is a tech-to-see, below which you will not even be aware of the existence of a unit (consider barbarians unable to see spy satellites overhead).  Then there is a tech-to-use, which you must have in order to do anything with the unit. The tech-to-understand and tech-on-acquisition are points at which your side can increase its tech level just by owning a unit, and finally the tech-to-build is what you must have to create new units of the given type.

See the appropriate sections below to find out how to do research and espionage to increase your tech level.

Side Classes
------------

In some games, several sides may be very similar, while being very different from other sides in the same game. These similar sides can be given the same side class. Units may then be restricted to be usable only by the sides in a particular class.  (Note that this is different from tech level, which allows units to be used by any side that has managed to acquire a sufficiently high tech level.)

Self-Units
----------

A self-unit is one that represents your whole side in some way. For instance, in a dungeon exploration game, your ``side'' might consist of an adventurer (you), your possessions, your followers, and perhaps more. In such a case, if the adventurer dies or is captured, then the game is over for that side.

[describe change of self-unit etc?]

Personalizing Your Side
-----------------------

[Whole section is hard to understand]

In order to tell everybody apart, it is possible to define and record your side name and a distinct emblem.  You can have different identities for different scenarios, and a default that applies to all others.

The name is a proper noun such as "Poland", the noun is what you would call an individual, such as "Pole", the plural is for more than one, and <adj> is the adjective for things on that side, such as "Polish". The color scheme is a comma-separated list of color names, and <image name> names some sort of image file (like a bitmap).

The image may be of any size and combination of colors, with the caveat that it may not always work correctly.  For instance, two subtly different shades may get fused into a single solid color.  The emblem should also be small enough to fit reasonably into unit icons. As a rule, most national flags will fit into a 7x5 rectangle, and coats of arms into a 7x9 region. The color scheme should be useful by itself, when the unit icons are too small to fit the emblem.

Xconq will not allow you to have the same name, color, or emblem as another player in the same game.

The interface-specific side configuration uses the favored mechanism for that interface (if one is defined). You should check with the interface documentation for more details.

Moving the Units
================

Once the first turn begins (and any pre-move backdrop activity has happened, see below), you can begin looking at the display and moving your units. Depending on the game design and startup options, you may or may not be moving simultaneously with the other players. If not, then the players move sequentially, in the order that their sides are listed in any display. Although all units conceptually act simultaneously, they actually act one at a time, in an order determined by various factors that will be described later.

Turn Setup
----------

First, Xconq computes the number of action points available to each unit. Each unit gets an increment of action points equal to its acp-per-turn.  Actions during a turn reduce this down; when it reaches a value less than the cost of any action, unit cannot do anything more until the next turn.

The range of action points for a unit is normally 0 up to the value of acp-per-turn, but the parameters acp-min and acp-max may allow for an extended range. You use this range by allowing a unit to accumulate extra action points by doing nothing for several turns, or to recover from an activity that used many action points all at once. Think of this as a sort of temporary action ``debt''. Units in debt at the beginning of a turn cannot act during that turn.

Types of Actions
----------------

Actions are the most basic kinds of things your units can do. During play, the interface will usually give you capabilities that are easy to use, such as the ability to drag a unit and have it try to get there somehow, but all such input eventually breaks down into sequences of actions. You will therefore find it useful to know all the types of actions available.

Movement Group:

  * Move to a given location. The unit being moved may be in a transport or out in the open, the destination is any location in the open (this will usually, but not always, be an adjacent cell), and may be at any altitude allowed for the unit.

  * Enter a given transport.  The transport need not be on the same side as the entering unit.

Combat Group:

  * Attack a given unit.

  * Overrun a given location.  This basically means ``attempt to occupy the destination, chasing everybody else out''.

  * Fire at a given unit, possibly with a given material.

  * Fire into a given location, possibly with a given material.

  * Capture a given unit.

  * Detonate at a given location.

Construction Group:

  * Research a given unit type.

  * Tool up to build a given unit type.

  * Create a unit of the given type.  The unit will usually be incomplete.

  * Build a given unit towards completion.

  * Repair a given unit.

Unit Manipulation Group:

  * Disband a given unit.

  * Move part of a unit, either to another given unit, or creating a new unit.

  * Change side of a given unit to a given side.

  * Change type of a given unit to a given type.

Material Manipulation Group:

  * Produce a given quantity of a given material type.

  * Transfer a quantity of a given material type to a given unit.

Terrain Manipulation Group:

  * Add terrain of a given type to a given location.

  * Remove terrain of a given type from a given location.

In general, all of these actions allow the acting unit to do the action on another unit. For instance, a transport can pick up or drop off a non-moving unit.

Not all interfaces can be guaranteed to allow the most general forms of all these actions!

Movement
--------

Movement into a cell is easy to request, but each game will have many rules constraining possible moves, depending both on the unit and the terrain it is moving over. Certain kinds of terrain cost extra points to enter, leave, or cross.  The destination must almost always be adjacent to the unit's current location.

The other kind of action is to enter/leave a transport. The only argument is the unit to enter, but again the constraints are complicated. The transport must have sufficient space, both the entering unit and the transport must have sufficient mp and acp to complete the move, and they must be able to cross intervening terrain.

In some games, you may be able to make one of your units leave the world entirely.  Sometimes this will seem like a good idea, perhaps to keep a trapped unit from falling into enemy hands, or because you win the game by leaving through a designated place. To do this, you just direct your unit (which must already be at the edge of the world) to move into one of the cells along the edge. If the departure is allowed, then the unit will simply vanish and be out of the game permanently.

In other games, you may be able to do a border slide. This is where a unit can jump to a non-adjacent cell if the two cells have a border whose endpoints touch the starting and ending cell.  This is typically allowed in games so that ships can go through narrow straits.

Combat
------

     War is a matter of vital importance to the State; the province of life or death; the road to survival or ruin.  It is mandatory that it be thoroughly studied.  -- SUN TZU (ca 400 BC)

There are two basic kinds of combat, each with two versions. A unit can attack or overrun, meaning that it comes to grips with an enemy in some way, or it can fire, meaning that it keeps its position and throws rocks or whatever at a target.

Attack is directed at a particular unit, while overrun is a more complex action where the unit attempts to clear enough units from a given location so that it can move into it.

The general idea is that a unit wishing to attack picks a position or unit to attack, Xconq computes the defender's response, then the outcome is determined.

In many games, that will be the end of a fight. In others, the units remain engaged in a battle, and they cannot do any other type of action until they have disengaged completely.

Firing can happen at long ranges, up to the range of a unit. It may or may not involve using a specific material as ammunition; if the game gives you a choice, you will have to choose which, or else all possible types will be used. You can fire at a specific unit if you can see it, otherwise you will have to fire into a cell. [presumably with less effectiveness]

Some units are capable of capturing other units, with a probability depending on the types of both units involved.  If the capture attempt is successful, the capturer will move into the cell if possible, either as occupant or transport.  In some games, the capturer may be all or partially disbanded, to serve as guards. Capture may also occur as a side effect of a normal attack.

Detonation is a special kind of ``combat'' available to some units. The action requires a location - either the unit's position or a nearby cell. Upon detonation, the detonating unit may lose some hp and even die (changing to its ``wrecked type'', if defined, or else vanishing). At the same time, it makes one hit on any units within its radius of effect.  Detonation may also be triggered automatically, such as by damage to the unit or even by another unit appearing nearby.

Research
--------

Research increases a side's tech for the unit type being researched. Although you can only research a specific type of unit, some game designs allow for a crossover effect, where increases in the tech level for one type also increases the level in others.

You can have more than one researcher researching the same type, and thereby speed up your progress, but some games put a ceiling (tech-per-turn) on how much progress you can make in one turn.

Toolup
------

Tooling up prepares a unit to create or construct the desired type. As with research, game designs may allow a crossover effect for tooling. Tooling may also decline gradually over time; this is called tooling attrition.

Construction
------------

Construction of a unit happens in two steps; creation and building towards completion. Most interfaces will also schedule research and toolup actions if a unit is told to build something that is still beyond its capabilities.

Creation is the actual step of bringing a new unit into existence. If the new unit is complete, then it can be used immediately. If not (the usual case), then the incomplete unit will exist and belong to your side, but be unable to do anything at all. Incomplete transports cannot have any occupants, unless they are types capable of completing the transport.

Completion is achieved by doing completion actions on the unit. Multiple units can all work on completing the same unit, but they must be sufficiently close, within a range defined by the game (usually the same or an adjacent cell).

It is usually the case that the same unit will be able to both create and complete a unit, but if not, you will have to pay special attention to your construction plan, since an incomplete unit cannot (usually) do anything to help itself along.  In some games, there is a level of completion past which the unit will start working on itself automatically, and eventually become complete without any further action.

Note that multi-part units will be considered ``complete'' when just one of their parts is completed.  Again, most interfaces will have the builder continue growing the just-completed unit as long as it sticks around.

Repair
------

Repair restores lost hit points to a unit. Repairs can be done by the damaged unit itself, if it is not too badly damaged, or by another unit that is close enough nearby.

Some games also feature automatic hit point recovery, so you don't have always to remember to do explicit repair actions.

Disbanding
----------

Disbanding is voluntary loss of hp, ultimately resulting in the disappearance of the unit. Most games only allow it for a few types of units.

Units with occupants can disband, but only if the occupants are unaffected by the action.  If unit would vanish or lose transport capacity, then the occupants must be disbanded or removed first.

Moving Parts
------------

In games where units are of variable size, you can shift one or more parts of a multi-part unit to another unit.

Changing Side
-------------

Changing side means moving a unit from the control of one side to another.  Not all types of units will allow this!

Changing Type
-------------

A few games allow a unit to change its type voluntarily.

Production and Transfer
-----------------------

Production is how a unit can produce a quantity of a material.

In many games, units already have a base production that is the amount of material that they produce automatically each turn. This will often depend on the terrain, so that explorers in the forest will always ``produce'' enough water to drink each turn, but will start to use up their water supply when in the desert.

Often there will be plenty of some type of material in the world, but the problem is getting it from the units that have a lot, to the units that need it badly.  The transfer action is how you move supply from one unit to another.

As with production, many games have some automatic transfers set up.  For instance, games involving aircraft generally refuel them automatically whenever the aircraft has landed in a place with fuel to spare.

Changing the Terrain
--------------------

In some games, units can add or remove borders, connections, or coatings, or may be able to change the overall type of terrain in a cell.

Automation of Units and Sides
=============================

Specifying the exact sequence of actions and their operands for every single unit would be mind-numbingly complex. It's not very realistic either! Therefore, Xconq includes several levels of automation for human players.

The elements of automation are the task, the plan, the doctrine, and the strategy.  These are related to each other by goals.

Tasks are single activities of a unit that require one or more actions to accomplish.  Examples of tasks include moving to a given position, or waiting 15 turns to be picked up by a transport.

A plan is the unit's object that expresses its decided-upon behavior. Elements of a plan include a type, goal, and task queue, as well as more specific slots, such as a pointer to the unit currently under construction. All units that can do actions have a plan.

The doctrine is the set of parameters governing how the side will play and how its units should work generally.  For instance, per-unit doctrine specifies the point which a unit low on supply should start to look for a place to replenish itself.

The strategy and associated subobjects is what an AI uses to make all the decisions about what to do.  This object is not directly visible, unless the AI is acting as your assistant and the interface includes such a display.

Of all these types of objects, only the doctrine can be manipulated directly;  all others are implicitly changed as a result of player commands, which are different for each interface.

Doctrine
--------

Players can set doctrine and use it in subsequent games, either for all games or just particular ones (see side config section).

  * wait-for-orders

     This is true if a unit should wait for explicit orders to be issued. If false, the unit should make up some sort of default plan and follow it.

     [add rest of doctrine]

Standard Types of Tasks
-----------------------

Tasks that a unit can do include:

  * Wait for an explicit command.

  * Stand sentry at its current location.

  * Move in the given direction.

  * Move to within a given distance of the given location.

  * Move towards another given unit.

  * Patrol an area around one or two given points.

  * Attempt to hit a unit at a given location.

  * Attempt to capture a unit at a given location.

  * Resupply.

Time Limits
-----------

One reason to be concerned about automating your units is that some game designs define real-time limits on the length of a game. For instance, the game might be set to end in one hour, a single turn might be limited to always last at most 2 minutes, or your side might be limited to 15 minutes of playing time, in the manner of a chess clock. If such limits are in effect, your display should be able to show you how much time you have left at any moment; pay attention!

When you run out of time, you are not automatically taken out of the game, but you can no longer give any orders.  Units that are already on automatic will continue to act.

The game design may give you a limited number of ``timeouts'' that you can call to stop the clock. The timeout ends when you order a unit to do something.

Environmental Conditions
========================

Some games include environmental effects, which includes what we normally think of as weather; the temperature, clouds, wind, rainfall, snowfall, and snow cover on the ground.

The temperature falls in a range specified by the game, and may be computed in different ways depending on the game design, but typically depends on terrain, latitude, the severity of the seasons, and elevation. Temperature may also vary randomly from turn to turn and cell to cell. The contribution of each of these to the final temperature is up to the game design, as is the effect of temperature. [explain effects]

Cloud layers may appear in levels above the surface. Their chief effect is to affect the seeing of units on the other side of the clouds.

Wind affects the weather by causing clouds and storms to move around. Certain unit types, such as sailing ships and balloons, may depend on the wind to move around.

Games may define that the world represents part of a tilted sphere, and that poles and equator correspond to various latitudes, which has the effect of producing seasons. The game specifies the temperature extremes for poles and equator, for both midsummer and midwinter, then the weather phase interpolates to get the average temperature for the current turn and at each latitude in the world.

Economy
=======

The economy in Xconq is based upon materials; if a game does not define any material types at all, then there is no economy.

Consumption
-----------

Units consume their supplies, both in the course of existence, and by motion/combat. The rate depends on game and unit type; it consists of an overhead consumed each turn without fail, and consumption for each cell of movement. The total is a max, not a sum, since units with a constant consumption rate are not likely to need additional supplies to move (consider foot soldiers who eat as much sitting around as they do walking). Supplies may also be consumed for production and repair, again depending on game and unit types, but this consumption happens during the build phase. Consumption is not affected by the situation of the consuming unit; armies in troop transports eat just as much as when in the field.

Movement of Materials
---------------------

Excess production is discarded, unless it can be unloaded into the producer's occupying units, or distributed to nearby units via supply lines.  Supply lines automatically exist between units that are close enough (as decreed by the game), and there is no need for explicit manipulation.

Supply line length depends on the game and the units on both ends, but is not affected by the intervening terrain. Supply redistribution is managed by logistics experts, who are ignorant of the war effort and seek only to even everything out. The redistribution method is rather adhoc; units try to get rid of all their excess supply, and try to take up supply from other units within supply range.  Each direction is controlled independently, so for instance airplanes can get automatically refueled from a nearby city, but not from each other.  No unit will transfer all of its supply via supply lines. Normally units in the same cell can exchange supplies, but some games can disable this behavior, so that explicit transfer using the give and take commands is always necessary.

Random Events
=============

Some games may include random events. These are usually rare, but not always - be sure you know the odds!

Accidents
---------

For some types of units in some types of terrain, there is a chance for an accident to wreck or eliminate the unit instantly. This depends on both unit type and terrain type. If the accident occurs, the unit is wrecked or eliminated along with all its occupants.

Attrition
---------

Attrition is ``slow death''; it takes away some number of hit points each time it occurs. The rate of attrition depends on unit type and terrain or transport type.

Revolt/Surrender
----------------

Revolts and surrenders are really the same sorts of occurrence; a unit changes sides spontaneously, perhaps to independence, perhaps to the side of a nearby unit. [???] Occupants will either change over or be killed. Any plans will be cancelled.

Surrender only occurs if a unit is capable of capture is present.  The capturing unit does not move. Occupants of the surrendering unit also change over or die. Chance of surrender is increased by low unit morale.

Scoring
=======

Different games can have different ways for players to win or lose. Some games may not have any scoring at all. You should be aware of this before you start to play the game!

In Xconq, scoring is implemented by a game design's scorekeepers. Each scorekeeper tests some sort of condition and/or maintains a numeric score. Scorekeepers also define when they run (perhaps only during certain turns or certain times within a turn) and which sides to look at. Each scorekeeper is independent of the others, so it only takes one to decide that you won or lost.

In a game with many players, winning and losing can be a complicated issue; read the conditions carefully. A scorekeeper can also decide to declare a game to be a draw and end it on the spot.

Once a side has won, it is out of the game. Some scorekeepers only allow one winner, others allow several; in those cases, the scorekeeper will say what happens to the winning side's units.

Once a side has lost, it cannot be brought back into a game, even if another side tries to give it some more units or otherwise to reverse things.

Finally, some games may record everybody's final scores into a file.

Last Side Wins
--------------

The most common form of scoring in Xconq is called last-side-wins.  It is basically a fight to the death; any side that loses all of its units loses, and the last side with any units remaining is declared the winner. It is possible that more than one side loses all its units at the same time, in which case the game is declared a draw.

Since this would sometimes lead to bizarre stalemates (a submarine could hide at sea, thus preventing the side from losing, for instance), many games also define a point value for units. In such cases, last-side-wins makes a side lose when the sum of point values of all its units is zero.

[following sections should help player interpret scorekeepers]

Occupation
----------

Unit Counts
-----------

Playing Hints
=============

Informal alliances frequently happen in games involving more than two people, so I have a few words of advice.  First, an alliance between two of the players is almost certain in a three-person game, and inevitably results in the "odd man out" being quickly defeated.  In four-person games, the alliances could be decided after looking at the map via a command-line option, so that one pair is not hopelessly separated.  Five or more players is going to be a free-for-all of formal and informal alliances. Some scenarios are designed with a particular number of players in mind.

Technical Details
=================

The coordinate system is ``oblique'', with the X-axis in the usual horizontal, and the Y-axis vertical, but tilted to the right at a 60-degree angle.

           Y
          /
         /
     ---------X
       /
      /